Duplicate sysevent registration for SYSEVENT_IPV6_TOGGLE. Lines 620-621 are identical to lines 623-624, causing the same event to be registered twice with the same parameters.

Format string expects integer values (%d) but provides strings. The format specifiers should be %s to match the ternary expressions that output strings.

Corrected spelling of 'Canculate' to 'Calculate'.

Logic error: the condition checks if both addrAssigned and prefixAssigned are false, but according to the comment and context, the intention is to construct a WAN address when IANA is not assigned but IAPD is received. The condition should be if(!pDhcpv6Data->addrAssigned && pDhcpv6Data->prefixAssigned) to match the stated behavior.

Comment lacks proper spacing. Should be '// Disable accept_ra' with space after '//'.

Corrected spelling of 'Canculate' to 'Calculate'.

In DEL_ADDR, ip -6 route flush match is run with the interface IPv6 host address (...match <addr>). That will only flush routes whose destination matches that /128, and will not remove routes for the delegated prefix (e.g., the ip -6 route add <sitePrefix> dev brlan0 route added during PD handling). Please flush based on the delegated prefix (or remove the specific prefix route you added) rather than matching the /128 address.

WanMgr_SendMsgToIHC now dereferences p_VirtIf unconditionally and no longer validates that the IPv4/IPv6 address fields are populated before sending (the previous implementation rejected empty/"(null)" values). Please add a null check for p_VirtIf and validate p_VirtIf->IP.Ipv4Data.ip / p_VirtIf->IP.Ipv6Data.address for the relevant message types to avoid sending empty addresses (or crashing if p_VirtIf is unexpectedly null).

The new docstring for setUpLanPrefixIPv6 says it "Sets up the IPv6 /128 address for the LAN bridge" and that it "creates" the address, but the implementation no longer assigns an IPv6 address to brlan0 (it only sets sysevents and adds a route). Please update the comment to match the actual behavior (or restore the missing address assignment if it is still required).

wanmgr_construct_wan_address_from_IAPD calls WanMgr_create_eui64_ipv6_address, but that helper is only compiled when FEATURE_RDKB_CONFIGURABLE_WAN_INTERFACE is defined (it is static inside that #if). Since wanmgr_construct_wan_address_from_IAPD is compiled unconditionally, builds that don't define FEATURE_RDKB_CONFIGURABLE_WAN_INTERFACE will fail (undefined symbol / implicit declaration). Please either move wanmgr_construct_wan_address_from_IAPD under the same feature guard, or provide a non-conditional implementation/declaration for the EUI-64 helper (or a fallback path).

cmdLine is only 128 bytes, but the new commands include an IPv6 literal (up to ~45 chars) plus an interface name up to BUFLEN_64 (DML_VIRTUAL_IFACE.Name), which can exceed 128 and get truncated by snprintf, causing the system action to fail. Please increase the buffer (e.g., BUFLEN_256) or compute the required length to ensure the full command is preserved.

wanmgr_construct_wan_address_from_IAPD sets addrAssigned=true and returns 0 regardless of whether address generation or ip -6 addr add actually succeeded (return value from WanMgr_create_eui64_ipv6_address is ignored; WanManager_DoSystemActionWithStatus failure is only logged). This can leave WanManager believing an IPv6 address exists when it does not. Please check these return codes and propagate failure (return -1 and avoid updating addrAssigned / sysevents on failure).

wanmgr_construct_wan_address_from_IAPD writes directly to stderr (fprintf(stderr, ...)) on parse failure. This bypasses the component logging used elsewhere and may not be captured in production logs. Please use the existing CcspTraceError logging (and include the offending prefix) instead of writing to stderr.

copyDhcpv6Data is a copy/helper routine but now has side effects (it may call wanmgr_construct_wan_address_from_IAPD, which runs ip -6 addr add and sets sysevents). Since DHCPv6 lease updates can arrive multiple times, this risks repeatedly trying to add the same /128 address (and doing potentially slow system calls while holding DhcpClientEvents_mutex). Please keep copyDhcpv6Data pure and move the WAN-address construction to the event-handling logic with proper idempotency (e.g., use ip -6 addr replace or check if the address is already present before adding).

This placeholder TODO (//TODO : **************************** Check this ************************) is not actionable and will be hard to triage later. Please either remove it or replace it with a specific TODO that states what needs to be verified and under what conditions (ideally with a ticket reference).

wanmgr_dhcp_event_handler.c calls wanmgr_construct_wan_address_from_IAPD() but does not include the header that declares it (wanmgr_dhcpv6_apis.h). This will rely on an implicit declaration in some toolchains (or fail to compile under C99/C11 with -Werror=implicit-function-declaration). Please include the proper header or add a forward declaration.

The docstring says this function “sets up the IPv6 /128 address for the LAN bridge” and “creates an IPv6 /128 address”, but the current implementation no longer assigns an address on brlan0 (it only derives an address and sets sysevents). Update the comment to reflect the actual behavior (or restore the address assignment if it’s still required here).

The added //TODO : **************************** Check this ************************ is a placeholder and doesn’t describe an actionable task. Please replace it with a specific TODO (what/why) and ideally a ticket reference, or remove it if not needed.

If ip -6 addr add ... fails, the function still continues and returns success. Propagate the failure (return -1) so callers don’t treat IPv6 as configured when it isn’t.

ip -6 route flush match expects a prefix/CIDR. Flushing with p_VirtIf->IP.Ipv6Data.address (without /128) is likely a no-op/error and won’t remove routes for the delegated prefix. Use an appropriate CIDR (e.g., the delegated prefix in sitePrefix or %s/128 for the host route) and keep the first argument to WanManager_DoSystemActionWithStatus as a stable log tag rather than the full command string.

Before sending IPOE_MSG_WAN_CONNECTION_IPV6_UP, validate that p_VirtIf->IP.Ipv6Data.address is non-empty (and ideally a valid IPv6 string). Otherwise IHC can receive an “UP” message with an empty/invalid IPv6 address.

This helper is documented as returning -1 on failure, but it always returns 0 even when a system command fails. Propagate the command failure status (and return -1) so callers can react appropriately.

wanmgr_construct_wan_address_from_IAPD(&Ipv6DataNew) return value is ignored, but pNewIpcMsg->addrAssigned is forced true. If construction/assignment fails, IPv6 will be treated as up with no usable address. Gate addrAssigned updates on successful construction and handle the failure path.

Before sending IPOE_MSG_WAN_CONNECTION_UP, validate that p_VirtIf->IP.Ipv4Data.ip is non-empty (and ideally a valid IPv4 string). Otherwise IHC can receive an “UP” message with an empty/invalid IPv4 address.